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Remarks 

In the interest of clarity, the paragraph numbers hereafter match the paragraph 
numbers in the Office Action. 

1-2. The Office Action rejected each of claims 9 and 10 as anticipated by 
Morange. Application respectfully traverses this rejection. 

Today medical enterprise information technology systems often include a huge 
number of different applications run on multiple different legacy systems where each 
system uses slightly different addressing and identifying schemes which makes it 
extremely difficult for the user of one application to access information controlled or 
stored by another other applications. The present invention overcomes these 
difficulties by providing an exchange server that stores information regarding each 
enterprise patient including different identifiers used by each of the applications for 
each patient as well as abstracts or the like that are associated with each event for 
each patient irrespective of which application originated the event related to the 
abstract. Thus, if there are 100 applications and each originates 20 events for a 
specific patient, the exchange server would store 2000 abstracts for events related to 
the patient along with potentially 100 different patient identifiers (e.g., numbers) 
corresponding to the patient. 

To facilitate access to the abstracts stored by the exchange server as well as to 
the more detailed event records stored by the applications, the server enables two 
different types of interfaces, a "get updates" interface and a "get detail" interface. As 
the labels imply, the "get updates" interface enables a system user to obtain relatively 
general information about events associated with a patient while the "get details" 
interface enables a system user to obtain more detailed information about specific 
events. The general information is accessible directly from the exchange server in the 
form of the abstracts while the more detailed information is accessible by the exchange 
server acting as an intermediary between two applications to obtain the detailed 
information from the application that originates an event and providing the detailed 
information to the requesting application. 
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Consistent with the above, claim 9 requires, among other things, a process for 
accessing event data associated with a patient including each of a get updates 
interface and a get detail interface where the update interface returns a description of 
events (e.g., an abstract for each event) that involve a specific patient and that are 
stored by other computer systems and the detail interface returns a detailed description 
of a single event associated with a patient. 

Turning to the portions of Morange cited in the Office Action (e.g., paragraphs 
94-108, 203 and Figs. 3 through 6), Applicant has analyzed those portions of the 
reference and is clear that none of the sections cited teaches or suggests a process 
that includes providing both an updates interface and a detail interface or anything akin 
thereto. To this end, Figs. 3-6 simply illustrate four different screen displays and 
teaches nothing about different interfaces for obtaining patient event updates on one 
hand and detailed event descriptions on the other hand. Applicant cannot see how one 
could interpret Figs. 3-6 as teaching different interfaces for showing event detail and 
event updates and requests that if the Examiner maintains this rejection, the Examiner 
more clearly point out which portions of the figures show or suggest detailed event 
descriptions and which show or suggest event updates. 

Similarly, paragraphs 94-108 have nothing to do with providing two different 
interface types for obtaining updates and details. Instead, paragraphs 94-108 discuss 
an emergency service system wherein, when an emergency occurs, a system can be 
used to generate a notice and to collect information (e.g., images) related to the 
emergency. To the extent that the Examiner maintains this rejection Applicant requests 
that the Examiner more specifically point out the sections of paragraphs 94 through 108 
that teach or even remotely suggest an interface for providing update information or 
detailed information related to a patient where the information is stored by other 
computer systems. Moreover, paragraph 203 discusses an RAN database that is a 
single repository for recordable elements and teaches nothing about different interfaces 
for presenting event updates and event details. 

For at least the above reasons Applicant believes that claim 9 and claim 10 
through dependency are novel over Morange and requests that this rejection be 
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withdrawn. 

3. With respect to claim 10, Morange teaches a RAN database that is a 
repository for all recordable elements that are generated in the system (see paragraph 
203, lines 15 through 26). In such a system there is no need to store the locations of 
systems that store data associated with events because all of the data is located in the 
single RAN repository. Thus, Morange teaches away from the limitations of claim 10 
and for this additional reason Applicant believes that claim 10 is novel over Morange. 

4-8. The Office Action rejected each of claims 1-8 and 1 1-13 as obvious over 
Morange in view of Felsher. Each of claims 1 and 5 have been amended to overcome 
this rejection. Claim 1 has been amended to now require that at least a subset of the 
patient identification numbers used by the applications are application distinct numbers 
for the patient (to this end see the patient cross reference number table at the top of the 
record in Fig. 2 of the present specification as well as original claim 3 hat included 
application specific identification codes). Felsher teaches that a single identification 
number is provided for each patient. For instance, a social security number may be 
provided and used across multiple applications to reference information associated with 
a specific patient. Here Applicant notes that Felsher's paragraph 274 teaches that an 
encryption code may change over time which has nothing to do with whether or not 
application specific patient identification numbers are used by a system. Thus, Felsher 
teaches away from a system that includes multiple different and application specific 
identification numbers for a specific patient. Morange fails to teach or suggest multiple 
identification numbers for a single person. For at least this reason Applicant believes 
claim 1 and claims that depend there from are non-obvious in light of Morange and 
Felsher. 

9. With respect to claim 5, claim 5 requires, among other things, a server 
that stores a table that includes separate identifying codes used for a patient by any 
application program where at least a subset of the codes are application distinct. Thus, 
this claim includes limitations similar to the application specific identification numbers 
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limitation of claim 1 and this claim is believed to be patentably distinct over the cited 
references for the same reason that claim 1 is distinct as described above. Here 
Applicant also notes that the additional sections of Felsher cited and specifically 
paragraphs 334-339 fail to teach or suggest application distinct patient identification 
codes and, instead, Felsher appears to assume that a single identifier is used within the 
system to identify a patient (see again the teachings in Felsher's paragraph 266 
regarding social security numbers or proxies therefore). 

Applicant has introduced no new matter in making the above remarks. In view of 
the above remarks, Applicant believes claims 1-13 of the present application recite 
patentable subject matter and allowance of the same is requested. No fee in addition 
to the fees already authorized in this and accompanying documentation is believed to 
be required to enter this amendment, however, if an additional fee is required, please 
charge Deposit Account No. 17-0055 in the amount of the fee. 
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